一句話摘要：
重大漏洞應變輸掉的關鍵，往往不是修補速度，而是資產盤點速度，如果你連自己有多少台系統用了那個有漏洞的套件都答不出來，再快的修補團隊也無用武之地。
當一個重大 CVE（例如影響廣泛的開源套件或核心中介軟體）被公開，全世界的攻擊者與資安團隊會在同一時間看到同一份公告，這是一場公平的賽跑。多數企業在這個時刻遭遇的第一個瓶頸，不是不知道怎麼修補，而是根本不知道自己的環境裡，哪些系統、哪些服務用了這個有問題的元件。沒有即時可查詢的軟體資產清冊（見 Day 19 SBOM），團隊只能靠人工搜尋、逐台盤點，而攻擊者的自動化掃描器，往往在公告發布後幾小時內就開始大規模掃描全網尋找可利用目標。
第一線 IT/SecOps 心聲： 「漏洞公告一出來，主管就在群組裡問『我們有沒有中？』，結果我們光是確認哪些系統用了那個套件，就花了快一整晚，修補反而是最後才輪到的事。」
決策層 / 業務單位迷思： 「這種重大漏洞新聞都上了，你們應該早就知道自己有沒有用到吧？怎麼還要查這麼久？」
當資產可見度不足，重大漏洞應變的黃金時間，會大量消耗在「找系統」而非「修系統」，而攻擊者的掃描速度，從來不會等企業盤點完畢。
重大 CVE 應變的實務流程，我會拆成五個階段，每個階段對應不同的速度要求與決策依據：
【重大 CVE 應變五階段流程】
多數企業把重心全部放在階段四（正式修補），但實務上階段二（資產範圍確認）與階段三（暫時緩解）才是決定應變速度的關鍵，因為正式 Patch 往往需要測試驗證才能上正式環境，中間的空窗期，靠的是暫時緩解措施撐住，而不是乾等 Patch。
以下是重大漏洞應變中，決定速度差異的關鍵能力對照：
| 應變能力 | 資產可見度低的企業 | 資產可見度高的企業 |
|---|---|---|
| 確認受影響範圍 | 需人工搜尋/詢問各系統負責人，耗時數小時到數天 | 查詢 SBOM/資產庫，數分鐘內出清單 |
| 暫時緩解決策 | 因不確定影響範圍，傾向全面下線保守處理 | 可精準針對受影響系統部署WAF規則 |
| 修補優先順序 | 憑印象或系統重要性主觀排序 | 依實際暴露面與資產重要性量化排序 |
實務追蹤範例（去識別化 CVE 應變時間軸紀錄）：
【重大 CVE 應變時間軸紀錄】
- D+0 20:15 官方發布漏洞公告，CVSS 9.8，已有公開 PoC
- D+0 20:30 IR 團隊啟動情資確認，交叉比對 CVE 編號與受影響版本
- D+0 22:45 完成內部資產盤點，確認 12 台伺服器使用受影響套件版本（因缺乏即時 SBOM，此步驟耗時逾 2 小時）
- D+0 23:10 針對 3 台對外暴露主機，先行部署 WAF 虛擬修補規則
- D+1 01:30 取得官方 Patch，於測試環境完成驗證
- D+1 06:00 完成 9 台內網主機正式修補
- D+1 14:00 完成剩餘 3 台對外主機分批修補（避開營運尖峰時段）
- D+2 09:00 完成全數修補驗證，結案並產出事後報告
檢討重點： 資產盤點耗時過長為本次應變最大瓶頸，已列為優先改善項目（導入 SBOM 自動化盤點工具）。
這份時間軸最有價值的地方，是它誠實記錄了資產盤點花了兩個多小時，這正是多數企業重大漏洞應變的真實寫照，也是為什麼後續會談到的 SBOM 治理，會是提升應變速度最直接的槓桿點。
實戰行動清單：
重大漏洞的賽跑，贏的往往不是修補技術最強的團隊，而是最快知道「自己中了沒」的團隊。攻擊者的掃描器不會等你盤點完畢，資產可見度的落差，才是決定黃金時間能不能守住的真正變數。工具會一直換版本，但「打仗前先知道自己有什麼」這件事，永遠是治理最基本卻最常被忽略的一步。
如果今晚突然公告一個重大 CVE，你有信心在多久之內查出公司有哪些系統受影響？如果答案是「不確定」，你覺得問題出在資產清冊不完整，還是查詢工具不夠即時？
【明日 DAY 15 痛點預告】
模組二即將收官，從黃金 72 小時指揮鏈、跨部門作戰、CTI 落地、威脅獵捕、EASM 到告警自動化與漏洞應變，這些拼圖組起來，指向的其實是同一個問題：你的 SOC，到底是在「應變」，還是已經升級成「韌性」？明天用一篇總結，收斂模組二的核心治理邏輯。
iThome鐵人賽
看影片追技術